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ZUS AMMENF AS SUNG 

Tokengesteuerte Bildung von drahtlosen Arbeitsgruppen 

Die Erfindung betrifft ein Verfahren fur das Betreiben eines Netzwerks zwischen 
mehreren Kommunikationsgeraten (1, 2, 5 bis 8) und insbesondere ein Verfahren fur das 
5 Betreiben eines Ad-hoc-Netzwerks zwischen Bluetooth-Geraten. Mehreren Kommuni- 
kationsgeraten (1, 2, 5 bis 8) ist jeweils ein Token (3, 9 bis 12, 15) zugeordnet, in dem 
die Gerateadresse des zugehorigen Gerates gespeichert ist. Mindestens ein Kommuni- 
kationsgerat dient als Tokenlesegerat (4, 13- und 14), urn die im Token (3, 9 bis 12, 15) 
gespeicherte Gerateadresse eines ersten Rommunikationsgerates (1) auszulesen. Anhand 
10 der Gerateadresse baut das Tokenlesegerat (4, 13 und 14) mit dem ersten Kommuni- 
kationsgerat (1) eine Verbindung auf und/oder die Gerateadresse wird durch das 
Tpkenlesegerat (4, 13 und 14) an mindestens ein zweites Kommunikationsgerat (2) 
ubermittelt. Das zweite Kommunikationsgerat (2) kann dann eine Verbindung mit dem 
ersten Koirfmunikationsgerat (I) aufbauen. 

15 

Fig. 2 



20 
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BESCHREIBUNG 

Tokengesteuerte Bildung von drahtlosen Arbeitsgruppen 

Die Erfindung betriflft ein Verfahren fur das Betreiben eines Netzwerks zwischen 
mehreren Kommunikationsgeraten und insbesondere ein Verfahren fur das Betreiben 
5 eines Ad-hoc-Netzwerks zwischen Bluetooth-Geraten. 

Drahtlose Ubertragungstechnologien wie z.B. Bluetooth ermoglichen mobilen Geraten 
spontan ohne vorherige Konfiguration ein Netzwerk zu bilden. Derartige Netzwerke 
werden als Ad-hoc-Netzwerke bezeichnet. Die Gerate eines Bluetooth Ad-hoc- 
10 Netzwerks arbeiten wahlweise als Master oder Slave in einem Netzwerk. Ein als Master 
arbeitendes Gerat koordiniert die gesamte Kommunikation in dem Netzwerk und 
. verwaltet eine Mehrzahl an Slaves. Er kann mit mehreren Slaves gleichzeitig eine 
Verbindung aufrechthalten/so dass sich eine sternfbrmige Netztopologie des Netzwerks 
ergibt. 

Eine drahtlose Verbindung zwischen dem Master und Slave wird durch eine Bluetooth 
Spezifikation realisiert, in der diverse elektronische Gerate Punkt-zu-Punkt oder Punkt- 
zu-Mehrpunkt Verbindimgen aufbauen konnen, urn Daten senden und empfangen zu 

konnen. Die Bluetooth Spezifikation zeichnet sich durch eine groBe Bandbreite im 

. ■ i 

20 Radiofrequenzbereich aus. Ein Verbindungsaufbau zwischen mehreren Bluetooth- 
Geraten entsteht mit Hilfe von Erkundungs(inquiiy)- und Anruf (page)-operationen, die 
ohne die Koordination- und. Verwaltungsfiinktionen des Masters nicht ordnungsgemafi 
durchgefiihrt werden konnten. Eine Erkundungsoperation dient dazu, dieGerateadresse 
eines entfernten Gerates zu ermitteln. 1st die Gerateadresse eines entfernten Gerates 

25 bekannt, kann man dann mit Hilfe einer Anrufoperation eine Kommunikationsverbindung 
mit dem entfernten Gerat aufbauen. 
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In der Veroffentlichung Bluetooth aktuell - Technik und Anwendungen" von Prof. Dr. 
Jorg Wollert, Elektronik 20/2001 S. 76 bis 81, wird die Bildung von sogenannten 
Piconetzen und insbesondere der Verbindungsaufbau beschrieben. In jedem Piconetz 
existiert ein Master, somit sind alle anderen Gerate des Piconetzes Slaves. Alle Gerate 

. 5 eines Piconetzes konnen miteinander liber den Master kommuniziereri, wobei ein Gerat 
gleichzeitig in mehreren Piconetzen sein kann und hochstens in einem Piconetz eine 
Funktion als Master ubernimmt. Weiterhin wird in der Veroffentlichung ein wesentliches 
Problem bei einer Anwendung des Bluetooth-Standards deutlich. Wenn ein Gerat nicht 
mit einem Piconetz verbunden ist, muss das Gerat selbst oder ein Master Erkundungs - 

10 und Anrufoperationen starten^ um in Verbindung mit dem Master zu treten. ■ 

Anhand eines Beispiels wird die Bildung eines Piconetzes erlautert. Ein Bluetooth-Gerat 
(BGi) fuhrt zunachst eine sogenannte Device-Discovery durch, die aus Anfrage einer 
Erkundungsoperation (inquiry) besteht. Ergebnis der Device-Discovery ist eine Liste mit 

1 5 den Ger&teadressen (GA2, . . . , GA„) aller erreichbaren Bluetooth-Grerate (BG2, . . . , BG n ) 
in der Nahe von BGi. Das Piconetz wird sukzessiv aufgebaut, d.h. als erstes baut BGi 
mittels einer Anrufoperation (page) eine Verbindung zu dem durch seine Gerateadresse 
GA 2 eindeutig ideritifizierten BG2 auf. Ergebnis ist ein Piconetz bestehend aus BGi und 
BG2. Das Gerat, das die Verbindung initiiert, wird Master des neuen Piconetzes. Also ist 

20 im Beispiel BGi der Master des Piconetzes und BG2 ein Slave. Danach baut BGi 
nacheinander Verbindungen zu den ubrigen Geraten BG3, BG„ auf, wodurch das 
Piconetz nach und nach vergroBert wird. 

Der Bluetooth-Standard definiert, wie ein Gerat mit einem anderen Gerat eine 
25 Verbindung aufbauen kann. Es wird aber nicht festgelegt, wer wann mit wem versuchen 
soil, eine Verbindung aufeubauen. Ein Verbindungsaufbau wird daher entweder durch 
einen Benutzer oder ein Applikationsprogramm ausgelost. 

Es konnen daher leicht Situationen entstehen, in denen mehrere Benutzer gleichzeitig 
30 versuchen, andere Gerate zu entdecken und Piconetze aufeubauen. Dies ist aus mehreren 
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Grunden probleraatisch. Zum einen konnen Gerate, die eine sog. Device-Discovery 
(Gerate Erkundung) gleichzeitig durchfuhren, sich gegenseitig nicht entdecken. Die 
Device r Discovery liefert also u.U. nur .ein unvollstandiges Ergebnis, zumal eine Device- 
Discovery typischerweise 30 bis 60 Sekunden lang dauert. 

5 

• Anstatt eines groBen Piconetzes konnen viele kleine Piconetze entstehen. Diese mussen 
dann umstandlich durch mehrere Master/Slave-RoIIentauschoperationen zu einem 
gemeinsamen Piconetz umgewandelt werden. 

' 10 Wahrend Benutzer bei drahtgebundenen Netzwerken durch Verfolgeri der Kabel leicht 
erkennen konnen, welche Gerate miteinander verbunden sihd, ist dies bei drahtlosen 
Netzen nur durch Programme, die die Netztopologie visualisieren, moglich. Da die 
Funkwellen durch Wande dringen, kann es leicht passieren, dass Gerate aus benach- 
barteh Raumen unbeabsichtigt und unbemerkt mit in das Piconetz aufgenommen werden, 
15 wodurch ein Sicherheitsrisiko entsteht. 

Der Aufbau eines Piconetzes ist daher fur unerfahrene Benutzer ein komplizierter 
Vorgang und erfordert ein aufeinander abgestimmtes Vorgehen aller Benutzer. 
AuBerdem kann ein Benutzer bei heutigen Bluetooth-Geraten die Freigabe von im Gerat 
20 gespeicherten Daten nicht auf ein speziellen Piconetz einschranken. 

i 

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren filr das Betreiben eines Ad-hoc- 
Netzwerks zwischen Bluetooth-Geraten bereit zu stellen, bei dem ein unkomplizierter 
Verbindunjgsaufbau stattfindet. 

25 

Die Aufgabe wird durch ein Verfahren der eingangs genannten Art dadurch gelost, dass 
mehreren Kommunikationsgeraten jeweils ein uber eine Gerateadresse ein Kommuni- 
kationsgerat identifizierender Token zugeordnet ist und mindestens ein Kommuni- 
kationsgerat als Tokenlesegerat dient, wobei die im Token gespeicherte Gerateadresse 
30 eines ersten Kommunikationsgerates durch das Tokenlesegerat ausgelesen wird, 
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- und das Tokenlesegerat anhand der Gerateadresse mit dem ersten 
Kommunikationsgerat eine Verbindung aufbaut und/oder 

- die Gerateadresse durch das Tokenlesegerat an mindestens ein zweites 
Kommunikationsgerat ubermittelt wird und das zweite Kommunikationsgerat eine 

5 Verbindung mit dem ersten Kommunikationsgerat' aufbaut. 

Jedem Kommunikationsgerat ist ein Token zugeordnet, der die Gerateadresse des 
Kommunikationsgerates auf einem „read-only" Speicher gespeichert hat. Jeder Token 
kann durch ein Tokenlesegerat ausgelesen werden, dabei wird die ausgelesene Gerate- 
adresse an das zweite Kommunikationsgerat weitergeleitet und/oder das Tokenlesegerat 
selbst stellt anhand der Gerateadresse eine Verbindung zu dem Kommunikationsgerat 
der ausgelesenen Gerateadresse her. Zum Auslesen des Tokens wird der Token in die 
Nahe Oder in das Tokenlesegerat selbst gebracht und verbleibt dort bis zum Abbruch der 
Verbindung. Urn die Verbindung abzubrechen entfemt ein Benutzer den Token aus dem 
15 Tokenlesegerat. 

Diese Losung ist besonders vorteilhaft, da der Verbindungsaufbau und -abbruch einfach 
durch das Einbringen oder Entfernen des Tokens aus dem Tokenlesegerat durch den 
Benutzer initiiert werden kann und somit besonders schnell und benutzerfreundlich ist. 

Das Tokenlesegerat kann beispielsweise die Gestalt eines Behalters haben, urn Token, 
welche z.B. die Form einer Mtinze oder eines Stiftes aufweisen, aufzunehmen. 

Der Behalter kann dabei so gestaltet sein, dass er nur eine bestimmte Anzahl Tokens 
25 aufiiehmen kann. Dadurch kann man die maximale Anzahl gleichzeitiger Verbindungen 
kontrollieren. Beispielsweise wird ein Projektor, der zu jedem Zeitpunkt nur von einem 
Benutzer benutzt werden kann, einen Tokenbehalter haben, der genau ein Token 
aufiiehmen kann. 

Das Speichern und Auslesen der Gerateadresse kann z.B. mit HUfe einer RFID- 
30 Technologie realisiert werden. 



20 
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Die Unteranspriiche haiben vorteiUiafte Weiterbildurigen der Erfindung zum Inhalt. 

Die Ausfiihrung gemaS Anspruch 2 betrifit insbesondere nach dem Bluetooth-Standard 
arbeitende Kommunikationsgerate, die als Bluetooth-Gerate bezeichnet werden. Durch 
5 die Benutzung von Tokens und passenden Tokenlesegeraten muss eine sonst ubliche 
Device-Discovery der Bluetooth-Gerate nicht mehr durchgefiihrt werden, da die 
Gerateadresse direkt aus dem Token ausgelesen werden kann. 

Nachdem das Tokenlesegerat eine Verbindung mit einem ersten Bluetooth-Gerat 
10 aufgebaut hat, bUden beide Bluetooth-Gerate ein sogenahntes Piconetz, in dem das 

Tokenlesegerat die Funktion eines Masters und das erste Bluetooth-Gerat die Funktion 
eines Slaves erfullen. Weitere Bluetooth-Gerate konnen als Slave Mitglieder des 
Piconetzes werden, indem ihre Tokens in das Tokenlesegerat gebracht werden und das 
Tokenlesegerat eine Verbindung zu ihnen aufgebaut hat. 

15 

Der Inhalt des Tokenlesegerats spiegelt also jederzeit die Zusammensetzung des 
Piconetzes wider und visualisiert so die aktuelle Netzwerktopologie des Netzes. 

Aus Sicherheitsgriinden kann beim Verbindungsaufbau ein im Token gespeichertes 
20 Passwort yerlangt werden. Zusatzlich kdnnen im Token Informationen ttber zu 

benutzende Ressourcen gespeichert werden. Solche Informationen kormen elektronische 
Pfade zu Dokumenten sein wie z.B. bei zu druckenden Dokumenten, die von einem 
bestimmten Drucker ausgegeben werden soUen oder bei gespeicherten PrSsentationen, 
1 die von einem Projektor angezeigt werden sollen. 1 



25 



Einem Bluetooth-Gerat konnen mehrere Token zugeordnet werden, indem mehrere 
Token eine gleiche Gerateadresse speichern. Die Token werden dann auf mehrere 
Tokenlesegerate verteUt. Dadurch kann ein als Slave arbeitendes Bluetooth-Gerat 
gleichzeitig in mehreren Piconetzen vertreten sein. 
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Urn zusatzlich jedem Token eine bestimmte Menge an Dokumenten zuordnen zu 
konnen, die zum Lesen den Mitgliedern eines Piconetzes freigegeben werden, enthalt 
. jeder Token eine Tokenidentifikationsnummer (Token-ID). Jedes Token speichert neben 
der Gerateadresse auch seine gerateweit eindeutige Token-ID ab. Ein Bluetooth-Gerat 
mit mehreren Token kann anhand der Token-ID jedem Token unterschiedliche 
Ddkumente zuweisen. 

Jedes Bluetooth-Gerat speichert dazu eine Zuordnung zwischen Token-ID und einem 
Namen einer Liste mit den diesem Token, zugeordneten, zum Lesen freigegebenen 
Dokumenten. 

Die. Liste der freigegebenen Dokumente besteht aus eingetragenen Dokumentennamen 
(File-ID) und einem zu jeder File-ID zugehorigen, physikalischen Laufwerkspfad. Beim 
Einlegen eines Tokens in ein Tokenlesegerat wird neben der Gerateadresse auch die 
Token-ID ausgelesen. 

Das als Master des Piconetzes arbeitende Bluetooth-Gerat legt eine Tabelle mit der 
Zuordnung der Gerateadresse und Token-IDs ab. Anhand der Gerateadresse kann sich 
das als Master arbeitende Bluetooth-Gerat mit einem als Slave arbeitenden Bluetooth- 
Gerat verbinden und ihm die entsprechende Token-ID mitteilen. 

Das als Slave arbeitenden Bluetooth-Gerat speichert eine Tabelle mit den ihm 
zugehorigen Token-IDs und den Gerateadressen der als Master arbeitenden Bluetqoth- 
Gerate, in denen sich die entsprechenden Tokens befinden. 

Weitere Einzelheiten, Merkmale und Vorteile derErfindung ergeben sich aus der folgen- 
den Beschreibung der Ausfuhrungsbeispiele anhand der Zeichnungen. Es zeigt: 

Fig. 1 ein erstes Bluetooth-Gerat mit einem Token und ein zweites Bluetooth-Gerat 

mit einem Tokenlesegerat, 
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Fig. 2 ein Bluetooth-Piconetz als Beispiel fiir ein Netzwerk mit schnurloser 

Ubertragung zwischen zwei Bluetooth-Geraten, . 

Fig. 3 bis 5 Aufbau eines Piconetzes mit einem Master und 
Fig. 6 und 7 Aufbau zweier Piconetze mit jeweils einem Master. 

5 

Fig. 1 zeigt zwei Bluetooth-Gerate 1 und 2. Bluetooth-Gerate sind mobile oder 
stationare Kommunikationsgerate wie z.B. Mobiltelefone, Notebooks, PDAs , 
Kassengerate, Zugangskontrollgerate oder Multimediakioske. Dem ersten Bluetopth- 
Gerat 1 ist ein Token 3 zugeordnet, der z. B. die Form eines Stiftes hat. Ein Token ist 
) jeweils stets nur einem mobilen Bluetooth-Gerat zugeordnet. Der Token 3 weist einen 
"read-only" Speicher auf; auf dem die Gerateadresse des. Bluetooth-Gerates 1 
gespeichert ist. 

/ • . . 

Das zweite Bluetooth-Gerat 2 steht in Verbindung mit einem Tokenlesegerat 4. Das 
Tokenlesegerat 4 hat die Gestalt eines Behalters und ist in der Lage den Token 
aufzunehmen sowie die auf der 3 gespeicherte Gerateadresse auszulesen, urn sie dem 
Bluetooth-Gerat 2 weiterzuleiten. 

Ein Benutzer des Bluetooth-Gerates 1, ,das ein Mobiltelefon ist, mochte das Bluetooth- 
Gerat 1 mit dem Bluetooth-Gerat 2 verbinden. Das Bluetooth-Gerat 2 ist ein PC, dessen 
Daten wie z.B. Adressbucheintrage durch das Mobiltelefon aktualisiert werden sollen. 
Dazu legt der Benutzer den Token 3 in das Tokenlesegerat 4. Das Tokenlesegerat 4 liest 
die Gerateadresse des Mobiltelefons aus und ubermittelt diese an den PC. Anhand der 
Gerateadresse kann der PC eine Verbindung zum Mobiltelefon aufbauen. 

In Fig. 2 sind die zwei in Verbindung stehenden Bluetooth-Gerate 1 und 2 dargestellt. 
Der Token 3 des Bluetooth-Gerates 1 befindet sich im Tokenlesegerat 4. Die Bluetooth- 
Gerate 1 und 2 tauschen Daten ttber die schnurlose Verbindung (in der Fig. 2 und » " 
folgenden Fig. als ein Doppelpfeil dargestellt) aus. 
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In Fig. 3 bis 5 wird der Aufbau eines Piconetzes mit einem Master demonstriert. Gleiche 
Oder entsprechende Eiemente und Komponenten in den folgenden Figuren werden 
jeweils mit gleichen BezugsziflEern bezeichnet. 

5. In Fig. 3 sind vier Bluetooth-Gerate gezeigt, welche nach einem Verbindungsaufbau die 
Rolle eines Slave in einem Piconetz erfttllen und deshalb als Slave 5 bis 8 bezeichnet 
werden. Jedem Slave 5 bis 8 ist ein Token 9 bis 12 zugeordnet: Jeder Token 9 bis 12 
verfugt uber einen "read-only" Speicher, der die Gerateadresse. des ihm zugeordneten 
Slaves 5 bis 8 sowie zusatzliche Informationen speichert. Zusatzliche Informationen 
1 0 kdnnen eine Token-Identifikationsnummer (Token-ID) oder elektronische Pfade sein, die 
auf elektronische Dokumente verweisen. Anhand der Token- ID kann ein Slave 5 bis 8 
seinen Token 9 bis 12 idehtifizieren. 1 

Weiterhin ist ein als Tokenlesegerat funktionierendes Bluetooth-Gerat dargestellt. Das 
15 Tokenlesegerat hat die Form eines Behalters und erfiillt nach einem Verbindungsaufbau 
die RoUe eines. Masters in dem Piconetz, deshalb wird.es als Master 13 bezeichnet. 

i 1 
* - 1 

Die Slaves 5 bis 8 sowie der Master 13 haben untereinander keine Verbindung. Die 
Token 9 bis 12 befinden sich in der Nahe des jeweiligen Slaves 5 bis 8. 

20 

In Fig. 4 sind die Slaves 5 bis 8 und ihre Token sowie der Master 13 dargestellt. Der 
Token 9 des Slaves 5 befindet sich im Behalter des Masterl3. 

Ein Benutzer des Slaves 5 mochte eine Verbindung zum Master 13 aufbauen. Dazu legt 
25 er den dem Slave 5 zugeordneten Token 9 in den Behalter des Masters 1 3 . Beim 

EQneinlegen des tokens 9 liest ein im Behalter des Masters 13 eingebauter Leser einen 
auf dem Token 9 gespeicherten Datensatz mit der Gerateadresse des Slaves 5 aus. Der 
Master 13 benutzt diese Gerateadresse, urn eine Verbindung mit dem Slave 5 aufzu- 
bauen. Dadurch entsteht ein Piconetz, das aus dem Master 13 und dem Slave 5 besteht. 
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In Fig. 5 sind wieder die Slaves 5 bis 8 und ihre Token 9 bis 12 sowie der Master 13 
. dargesteilt. Alle Token 9 bis 1 2 befindet sich im Behalter des Master 1 3 . 

Die Benutzer der Slave 6 bis 8 mochten eine Verbindung zum Master 13 aufbauen, urn 
5 somit als Knoten des Piconetzes an der Kommunikation teilzuhaben. Dazu legt jeder 
. Benutzer den entsprechenden Token 10 bis 1 1 in den Behalter des Masters 13. Beim 
Hineinlegen der Token 10 bis 12 in den Master 13 liest der Leser den auf dem Token 10 
bis 12 gespeicherten Datensatz mit der entsprechenden Gerateadresse aus und kann eine 
Verbindung zum der Gerateadresse entsprechenden Slave 6 bis 8 aufbauen. 

Nachdem der Master 13 alle Gerateadressen ausgelesen und mit jedem der Slaves 5 bis 8 
ein Verbindung aufgebaut hat, ist ein Piconetz mit den Slaves 5 bis 8 und einem Master 
13 in Stem-Topologie entstanden. Eine Zusammensetzung des Piconetzes spiegelt sich 
wider in dem Inhalte des Behalters. ' 

In Fig. ' 6 und 7 wird der Aufbau zweier Piconetze mit jeweils einem Master und 

i 

mehreren Slaves dargesteilt. Es wird auf die Beschreibung im Zusammenhang mit Figur 
3 bis 5 Bezug genommen, und nachfolgend werden nur die Unterschiede erlautert. 

In diesem Ausfiihrungsbeispiel ist dem Slave 5 zusatzlich zum Token 9 auch Token 15 
zugeordnet. Ein weiteres Tokenlesegerat ubernimmt die Rolle eines Masters und wird 
deshalb als Master 14 bezeichnet. 

Die in Fig. 6 dargestellten Master 13 und 14 beinhalten keine der Token, somit haben die 
Slaves 5 bis 8 keine Verbindung zum einem der Master 13 und 14. 

Um eine Verbindung zum Master 13 und Master 14 aufeubauen plaziert der Benutzer 
des Slaves 5. den Token 9 in deh Master 13 und den Token 15 in den Master 14. Beide 
Master lesen die auf dem jeweiligen Token 13 und 15 gespeicherte Geratesadresse des 
Slaves 5 aus und bauen dann jeweils eine Verbindung zum Slave 5 auf. 
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Analog legen die Benutzer. der Slaves 6 und 8 die Token 10 und 12 in den Behalter des . 
Masters 14 und dieser stellt jeweils eine Verbiridung zum Slave 6 und 8 auf. 
Der Token 1 1 des Slaves 7 wird in den Behalter des Masters 13 plaziert. Master 13 liest 
die Gerateadresse des Slaves .7 aus und baut eine Verbindung mit Slave 7 auf. 

Fig. 7 zeigt ein erstes Picqnetz, das aus den Slaves 5 und 7 sowie dem Master 13 
besteht. Die Token 1 1 und 9 befinden sich im Master 13. Ein zweites Piconetz besteht 
aus deh Slaves 5, 6 und 8 mit dem zugehorigen Master 14. Die token 10, 12 und 15 
befinden sich im Master 14. • \ 

Der Master 13 steht in Verbindung mit Slave 5 und 7. Der Master 14 hat eine 
Verbindung zum Slave 5, 6 und 8 aufgebaut. Slave 5 kann sowohl mit Master 13 als 
auch mit Master 14 kommiinizieren. 

Der Benutzer des Slaves 5 besitzt zwei Token 9 und 15, damit er fur unterschiedliche ' 
Benutzer unterschiedliche Dokumente zum Lesen freigeben kann. Jedem Token isf 
genau eine bestimmte Menge an Dokumenten zuzuordnen. Der Benutzer kann z.B. 
Tokgn 9 zwei Dokumenten Dl und D2 und Token 15 ein Dokument D3 zuordnen. Legt 
er nun Token 9 in den Behalter von Master 13 und Token 15 in den Behalter von Master 
14, erreicht er, dass Slave 7. des ersten Piconetzes und Master 13 die Dokumente Dl und 
D2 lesen konrien. Die Slaves 6 und 8 d&s zweiten Piconetzes und Master 14 konnen auf 
das Dokument D3 des Slaves 5 zugreifen. 

Am Beispiel des ersten Piconetzes wird die Freigabe von Dokumenten und eine 
zugrundeliegende Datenstruktur des Piconetzes erlautert. 

Der Slave 5 besitzt die Gerateadresse 01 02 03 04 05 06, Slave 7 wird durch die 
Gerateadresse OA 0B 0C 0D 0E OF eindeutig identifiziert, Master 13 hat 12 13 14 15 16 
17 als Gerateadresse und Master 14 hat die Gerateadresse 21 23 43 21 12 45. Die Token 
15 und 9 des Slaves 5 und Token 1 1 des Slaves 7 besitzen eine gerateweit eindeutige 
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Token-Identifikationsnummer (Token-ED). Jeder Token 15 und 9 speichert neben der 
Gerateadresse auch seine Token-ID ab. Der Token 9 hat die Token-ED 01 02 06, Token 
15 hat die Token-ID 03 05 07 und Token 1 1 besitzt 21 22 16 als Token-ID. Die . 
folgende Tabelle zeigt eine eindeutige Zuordnung des Tokens 9 zum Slave 5. Die 
5 Tabelle wird im Token 9 abgespeichert. 



Gerateadresse 


01 02 03 04 05 06 


Token-ID 


01 02 06 



Jeder Slave 5 und 7 besitzt eine Zuordnung zwischen Token-ED und einer 
Listenideritifikationsnummer, die. eine Liste kennzeichnet mit den diesem Token 
10 zugeordneten, zum Lesen freigegebenen Dokumenten. Fur die Token 9 und 15 des 
Slaves 5 ist die Zuordnung in der folgenden Tabelle dargesteUt. Die Tabelle.wird in 
Slave 5 gespeichert. 



Token-ID 


Listen-ID 


01 02 06 


1 


03 05 07 


2 



Einer Token-ED kdnnen auch mehrere Listen-BDs zugeordnet werden. 
Eine Liste der freigegebenen Dokiimente besteht pro Eintrag aus einer Dokumenten- 
Identifiicationseinheit (File-BD) und einem physikalischen Laufwerkspfad. Die folgende 
Tabelle zeigt die Liste mit Listen-ID = 1 . 



Liste zu Dokument-Listen-ID= 1 


File-ID 


Laufwerkspfad 


1 


C:\abc\test.doc 


2 


C:\temp\brief.doc 



i r 

1 *** r <•.< 
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Beim Einlegen des Tokens 9 in den Behalter des Masters 13 wird neben der 
Gerateadresse auch die Token-ID ausgelesen. 

Der Master 13 legt eine TabeUe mit einer Zuordnung aus Gerateadresse und Token-ID 
fur die Slaves 5 und 7 an. Die folgende TabeUe zeigt eine solche Zuordnung. Die TabeUe 
wird im Master 13 gespeichert. 



10 



Gerateadresse der Slaves 


Token-ID 


01 02 03 04 05 06 


01 02 06 


OA 0B OC OD OE OF 


21 22 16 

» 



eine 



Dann stellt der Master 13 wie zuvor beschrieben anhand der Gerateadresse , 
Verbindung mit dem entsprechenden Slave 5 und 7 auf. Dabei teilt der Master 13 dem 
Slave 5 die Token-ID des Tokens 9 mit. Analog wird dem Slave 7 die Token-ID des 
Tokens 1 1 durch den Master 13 mitgeteilt. ' 



Daraufhin legt der Slave 5 eine TabeUe mit der Token-ID und der Gerateadresse des 
15 Masters 13 an. Die TabeUe wird im Slave 5 gespeichert. 
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Token-ID 


Gerateadresse des Masters 


01 02 06 


12 13 14 15 16 17 


03 05 07 


21 23 43 21 12 45 



Die TabeUe enthalt auBerdem die analog von dem Master 14 an den Slave 5 ubertragene 
Token ID des Tokens 15 sowie die Gerateadresse des Masters 14. 

Eine Kommunikation zwischen dem Master 13 und Slave 5 und 7 wird durch in den 
Slaves 5 und 7 implementierte Softwareprogrammteile wie der Methoden 
GetFUeList(Token-ID) und GetFUe(Token-ID, File-ID) ausgelost. Anfragen werden aus 
Sicherheitsgriinden nur von dem zur Token-ID passenden Master 13 akzeptiert. Dazu 



13- 



-ft 

PHDE020151 



benutzt der Slave 5 die angelegte Tabelle, die die Zuordnung Token-ID zu Gerate- 
adresse des Masters 13 enthalt, Die Methode GetFileList(Token-ID) liefert die der 
Token-ID zugeordnete Liste der freigegebenen Dokumente. Die Methode GetFile 
(Token-ID, File-ID) liefert das durch die File-ID. spezinzierte Dokument zuriick. 
5 . ' 

Wenn eine Slave neii in das Piconetz hinzukommt, ruft der Master 13 die Methode 
GetFileList bei dem neuen Slave auf und verteilt das Ergebnis der Methode GetFileList 
sowie die Gerateadresse und die Token-ID an alle Slaves des Piconetzes. Der heue Slave 
richtet die Methode GetFileList und GetFile als Anfragen an den Master 13, der die 
10 Arifragen an die Slaves 5 und 7 weiterleitet. 

Verlasst der neue Slave das Piconetz, so teilt. der Master 13 alien verbliebenen Slaves 5 
und 7 mit, dass der neue Slave mit den zuvor freigegebenen Dokumenten nicht mehr 
verfugbar ist. . 
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PATENTANSPRttCHE 



1. Verfahren zum Betreiben eines Netzwerks zwischen tnehreren 
Kommunikationsgeraten(l, 2, 5 bis 8) mit jeweils einem ttber eine Gerateadresse ein 
Kommunikationsgerat (1, 2, 5 bis 8) identifizierenden Token (3, 9 bis 12, 15) und 
mindestens einem als Tokenlesegerat (4, 13 und 14) dienenden Kommunikationsgerat, 
5 wobei die im Token (3, 9 bis 12, 15) gespeicherte Gerateadresse eines ersten 

Kommunikationsgerates (1) durch das Tokenlesegerat (4, 13 und 14) ausgelesen wird, 

- und das Tokenlesegerat (4, 13 und 14) anhand der Gerateadresse mit dem ersten 
Kommunikationsgerat (1) eine Verbindung aufbaut undVoder 

- die Gerateadresse durch das Tokenlesegerat (4, 1 3 und 14) an mindestens ein 
10 zweites Kommunikationsgerat (2) ubermittelt wird und das zweite 

Kommunikationsgerat (2) eine Verbinduhg mit dem ersten Kommunikationsgerat (1) 
aufbaut. 

2. Verfahren nach Anspruch 1, 
15 dadurch gekennzeichnet 1 

dass das Netzwerk ein nach dem Bluetooth-Standard arbeitendes Netzwerk ist. 

3. Verfahren nach Anspruch 2, 
dadurch gekennzeichnet , 

10 dass mindestens das Tokenlesegerat (4, 13 und 14) und das erste Kommunikationsgerat 
(1) zur Bildung eines sogenannten Piconetzes vorgesehen sind. ' 
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4. Verfahren nach Anspruch 2, 
dadurch gekennzeichnet 

. dass das Tokenlesegerat (13 und 14) die Funktion eines Masters und weitere 
Kommunikationsgerate (i, 2, 5 bis 8) jeweils die Funktion eines Slaves des Netzwerks 
5 erfiUlen. 

5. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet , 

dass ein im Token (3, 9 bis 12, 15) gespeichertes PasswOrt durch das Tokenlesegerat (4, 
10 13 und 14) ausgelesen wird. 

6. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet « 
dass das Tokenlesegerat (4, 13 und 14) zur Aufeahnie einer bestimmten Anzahl an' ' 
15 Tokens (3, 9 bis 12, 15) vorgesehen ist. 

71 Verfahren nach Anspruch 1, 
dadurch g ekennzeichnet , 

dass der Token (3, 9 bis 12, 15) Infprmationen uber Ressourcen des Netzwerks enthalt. 
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8. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet , 

dass der Token (3, 9 bis 12, 15) Informationen uber eine Freigabe von Dokumenten 



enthalt. 
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9. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet , 

dass mehrere Token (9, 15) einem Kommunikationsgerat "(1, 2, 5 bis 8) zugeordnet sind 
und jedem Token (9, 15) eine Tokeriidentifikationsnummer (Token-ID) zugeordnet ist 

5 

10. Verfahren nach Anspruch 9, 
dadurch j g ekennzeichnftt 

dass eine Zuordnung der Tokenidentifikationsnummer und einem eine Liste mit 
Dokumenten identifizierenden Namen (Listen-ID) in einem als Slave arbeitenden 
10 Kommunikationsgerat (1; 2, 5 bis 8) gespeichert wird. 

11. Verfahren nach Anspruch 10, 
• dadurch gekennzeichnet , >■ 

dass die Liste mit Dokumenten aus einer Dokumentenidentifikationseinheit (File-ID) und 
einem der Dokumentenidentifikationseinheit zugeordneten Laufwerkspfad besteht. 

12. Verfahren nach Anspruch 9, 
dadurch gekennzeichnprf , 

dass ein als Master arbeitendes Kommunikationsgerat (13 und 14) eine aus 
Gerateadressen und Token-ID bestehende Zuordnung speichert. 
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13. Verfahren nach Anspruch 9, 
dadurch g ekennzeichnpt , 

dass das als Slave arbeitende Kommunikationsgerat (1, 2, 5 bis 8) eine Zuordnung *us 
25 Tokenidentifikationsnummern und Gerateadressen der als Master (13 und 14) 
arbeitenden Kommunikationsgerate speichert. 
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14. Kommunikatiqnssystem mit mehreren Kommuhikationsgeraten (1, 2, 5 bis 8) und 
jeweils einem uber eine Gerateadresse ein Kommunikationsgerat (1, 2, 5 bis 8) 
identifizierenden Token (3, 9 bis 12, 15) sowie mit mindestens einem als Tokenlesegerat 
, (4, 13 und 14) dienenden Kommunikationsgerat, bei dem ( 

- das Tokenlesegerat (4, 13 und 14) zum Auslesen der im Token (3, 9 bis 12, 15) 
gespeicherten Gerateadresse eines ersten Kommunikationsgerates (1) vorgesehen ist 
und 

- das Tokenlesegerat (4, 13 und 14) anhand der Gerateadresse mit dem ersten 
Kommunikationsgerat (1) zum Aufbau.einer Verbindung vorgesehen ist und / oder ' 

, das Tokenlesegerat (4, 13 und 14) zur. Ubermittlung der Gerateadresse an 

mindestens ein zweites Kommunikationsgerat (2) vorgesehen ist und das zweite 
Kommunikationsgerat (2) zum Aufbau einer Verbindung mit dem ersten 
Kommunikationsgerat (1) vorgesehen ist. 
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